1. Field of the Invention
The present invention relates generally to a mobile communication system, and in particular, to a method and apparatus for transmitting and receiving Packet Data Units (PDUs) in a User Equipment (UE) or a Node B.
2. Description of the Related Art
Currently, Long Term Evolution (LTE) standard is under discussion as the next generation mobile communication system succeeding the UMTS system. LTE is a technology for implementing communication for high-speed packet transmission at about 100 Mbps, aimed at deployment in around 2010. To this end, several schemes are now under discussion, and a typical one of the schemes moves a radio protocol function of a Radio Network Controller (RNC) to an e-Node B to maximally approximate it to radio channels.
FIG. 1 is a diagram illustrating an exemplary configuration of a next generation LTE mobile communication system.
Referring to FIG. 1, as illustrated, Evolved UMTS Radio Access Networks (E-UTRANs) 110 and 112 are simplified to a 2-node configuration of Evolved Node Bs (ENBs) (or Node Bs) 120, 122, 124, 126 and 128, and anchor nodes 130 and 132. A User Equipment (UE) 101 accesses an Internet Protocol (IP) network by means of the E-UTRANs 110 and 112.
The ENBs 120 to 128 correspond to the legacy Node Bs of the UMTS system, and are connected to the UE 101 over radio channels. Unlike the legacy Node Bs, the ENBs 120 to 128 perform more complex functions. In LTE, since all user traffics, including the real-time services such as Voice over IP (VoIP), are serviced over a shared channel, there is a need for an apparatus for gathering status information of UEs and performing scheduling using the information, and the ENBs 120 to 128 take charge of this function.
Like High Speed Downlink Packet Access (HSDPA) and/or High Speed Uplink Packet Access (HSUPA), LTE also has Hybrid Automatic Repeat reQuest (HARQ) performed between the ENBs 120 to 128 and the UE 101. However, since it is not possible to satisfy various Quality-of-Service (QoS) requirements only with HARQ, outer-ARQ can be performed in upper layers, and the outer-ARQ is also performed between the UE 101 and the ENBs 120 to 128.
To realize a data rate of a maximum of 100 Mbps, LTE is expected to use Orthogonal Frequency Division Multiplexing (OFDM) as a radio access technology in a 20-MHz bandwidth. In addition, Adaptive Modulation & Coding (AMC) that determines a modulation scheme and a channel coding rate depending on the channel status of UEs will be applied.
Many next generation mobile communication systems, including LTE, use both HARQ and ARQ as an error correction technique.
The term ‘HARQ’ as used herein refers to a technique for soft-combining previously received data with its retransmitted data without discarding the previously received data, thereby increasing a reception success rate. More specifically, an HARQ receiving side determines the presence/absence of an error in a received packet, and then sends an HARQ positive Acknowledgement (HARQ ACK) signal or an HARQ negative Acknowledgement (HARQ NACK) signal to a transmitting side according to the presence/absence of an error. Then the transmitting side carries out retransmission of the HARQ packet or transmission of a new HARQ packet according to the HARQ ACK/NACK signal. The HARQ receiving side soft-combines the retransmitted packet with the previously received packet to reduce an error occurrence rate.
The term ‘ARQ’ refers to a technique for checking sequence numbers of received packets, and issuing a retransmission request for a missing packet if any. This technique does not soft-combine the previously-received packet with its retransmitted packets. In the LTE system, the ARQ operation is managed by a Radio Link Control (RLC) protocol layer, and the HARQ operation is managed by a Media Access Control (MAC) or Physical (PHY) layer.
FIG. 2 is a diagram illustrating a protocol structure for an LTE system. In FIG. 2, layers of a transmitting side and a receiving side are shown in a symmetrical manner.
Referring to FIG. 2, an LTE system includes Packet Data Convergence Protocol (PDCP) entities 201 and 215, and RLC entities 203 and 213 per service. The PDCP entities 201 and 215 are in charge of an operation such as compression/decompression of an IP header. The RLC entity 203 reassembles RLC Service Data Units (SDUs) 217, or a packet output from the PDCP entity 201, in an RLC PDU 219 in an appropriate size, and the RLC entity 213 outputs RLC SDUs 227 to the PDCP entity 215 by combining an input RLC PDU 225, and performs an ARQ operation and the like.
MAC entities 205 and 211 are connected to several RLC entities 203 and 213 formed in one UE, and perform an operation of multiplexing the input RLC PDU 219 to a MAC PDU 221 and demultiplexing the RLC PDU 225 from a received MAC PDU 223.
Physical layers 207 and 209 make an OFDM symbol by channel-coding and modulating upper layer data and transmit the OFDM symbol over a radio channel; or demodulate and channel-decode OFDM symbols received over a radio channel and transfer the decoded OFDM symbols to an upper layer.
Undepicted HARQ entities possibly provided between the MAC layers 205 and 211 and the physical layers 207 and 209 exchange the MAC PDUs 221 and 223 with each other through a predetermined HARQ operation.
Generally, ‘Layer 2 (L2)’ refers to the PDCP, RLC and MAC layers 201 to 205 (211 to 215), and ‘Layer 1 (L1)’ refers to the physical layers 207 and 209.
The PDCP, RLC, MAC entities 201 to 205 (211 to 215) exist in pair for a transmitting side and a receiving side. For example, the transmitting-side RLC entity 203 and the receiving-side RLC entity 213 are associated with each other on a one-to-one basis.
FIG. 3 is a diagram illustrating a structure of RLC PDUs in a conventional mobile communication system.
Referring to FIG. 3, the transmitting-side RLC entity 203 transmits RLC PDUs 312 and 314 to the receiving-side RLC entity 213.
In structures of the conventional RLC PDUs 312 and 314, headers 311 and 313 include therein D/C field, Sequence Number field, P field, HE field, Length Indicator (LI) fields 321, 323 and 325, and Extension Bit fields 322, 324 and 326.
The LI fields 321, 323 and 325 are fields for generally indicating an end of each of RLC SDUs 301 to 304 included in the RLC PDUs 312 and 314, and the Extension Bit fields 322, 324 and 326 are fields for indicating whether the next succeeding field is an LI field or data (i.e., payload).
The D/C field is a field indicating whether the current transmission PDU is a data PDU or a control PDU, and Sequence Number indicates a transmission number according to a transmission order of PDUs. The P field is polling bits for a polling operation, and the HE field indicates whether the next transmission octet is a start of data or an LI field.
A description will now be made of structures of the RLC PDUs 312 and 314 in FIG. 3 when the RLC SDUs 301 and 302 are transmitted on one RLC PDU 312 and a part 327, which was cut out from the RLC SDU 302 without being transmitted in the previous transmission, is transmitted in the next RLC PDU 314 along with the RLC SDUs 303 and 304.
In FIG. 3, when several RLC SDUs 301 and 302 are included in one RLC PDU 312 or an RLC SDU 327, which was cut out without being transmitted in the previous transmission, is transmitted, the LI fields 321, 323 and 325 are each formed with 7 bits in the headers 311 and 313 in order to indicate the inclusion/partial-transmission, and the Extension Bit fields 322, 324 and 326 for indicating whether the next succeeding field is LI or data is added thereto.
Specifically, in FIG. 3, the LI field 321 included in the header 311 indicates an end point of the RLC SDU 301 in a payload of the RLC PDU 312, the LI field 323 included in the header 313 indicates an end point of the RLC SDU 302 in a payload of the RLC PDU 314, and the LI field 325 indicates an end point of the RLC SDU 303 in the payload of the RLC PDU 314.
Since the LI fields generally indicate end points of SDUs included in the payload of each PDU as stated above, when several SDUs are bound together in one PDU during transmission, the number of LI fields increases with the number of RLC SDUs included in the payload of the PDU.
The LI indicates an offset from a start point of the current transmission PDU up to an end point of an SDU which is transmitted together in the payload of the PDU. Therefore, the LI is not a simple indicator but expresses a substantial value, and the receiving-side RLC entity 213 separates each SDU from the PDU using the LI according to a math expression.
In the header of an RLC PDU, the LI and Extension Bit are formed together in one byte (i.e., octet), and the LI field is followed by the Extension Bit field.
When the transmitting-side RLC entity 203 transmits the RLC PDU generated as stated above, the receiving-side RLC entity 213 performs an operation of FIG. 4 to check the LI.
FIG. 4 is a flowchart illustrating an operation for checking the conventional Extension Bit and LI.
In step 401, the receiving-side RLC entity 213 extracts an octet including an LI field from a header of an RLC PDU received from the opposing RLC entity 203, and extracts Extension Bit by performing a masking work. The receiving-side RLC entity 213 checks in step 403 whether the extracted Extension Bit is ‘1’. If it is ‘1’, the receiving-side RLC entity 213 proceeds to step 405, and if it is not ‘1’, the receiving-side RLC entity 213 proceeds to step 407.
In step 405 where the extracted Extension Bit is ‘1’, the receiving-side RLC entity 213 determines that an LI field and an Extension Bit field of another RLC SDU exist in the next octet, and then proceeds to step 409. However, in step 407 where the extracted Extension Bit is not ‘1’, the receiving-side RLC entity 213 determines that data exists from the next octet, and then proceeds to step 409.
In step 409, since the extracted Extension Bit is present after the LI field, the receiving-side RLC entity 213 right-shifts the octet including the LI field by 1 bit before extracting the LI field, and checks LI included in the LI field in step 411.
To check an LI value included in an RLC PDU, the receiving-side RLC entity 213 of the conventional asynchronous system should perform masking for determining Extension Bit and then perform again a shift operation for LI after reading out a byte in which the LI is included. The shift operation should be performed for every octet including an LI field regardless of the contents of Extension Bit. Therefore, there is a demand for a scheme capable of efficiently checking LI in the receiving-side RLC entity 213.